• fix: denominate tron currencies as erc20 #33 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Greptile Summary

This PR is a temporary workaround for RequestNetwork/requestNetwork#1713: it re-labels the two Tron tokens (USDT-tron, USDC-tron) from "type": "TRC20" to "type": "ERC20" in the main token list, bumps the patch version from 1.5.0 to 1.5.1, and drops a TODO comment in the TokenType enum. The historical versions/v1.5.0.json snapshot is correctly left untouched; the new versions/v1.5.1.json snapshot will be auto-generated by the deploy workflow on the next release.

Key points from the review:

• Semantic collision risk: Marking Tron tokens as ERC20 while their network remains "tron" means any consumer that filters payment routes by type === "ERC20" alone will receive Tron addresses in an EVM context. Tron addresses are not valid EVM addresses, which can cause downstream failures (invalid ethers address normalisation, broken contract calls, etc.). Consumers should be explicitly informed they must guard with network !== "tron" for the duration of this workaround.
• TODO discoverability: The TODO comment lives on the TRC20 enum member, which is not directly connected to the mis-typed token records. Consider adding a comment closer to the Tron entries in token-list.json to make the workaround easier to find during a future fix.
• The version bump and preservation of v1.5.0.json follow the convention established by the deploy workflow correctly.

Confidence Score: 3/5

• Mergeable as a temporary workaround, but carries a real risk of breaking consumers that rely on the type field alone to route EVM operations.
• The change is intentional and documented, and the version/snapshot handling is correct. However, the semantic mismatch between type=ERC20 and network=tron is a genuine P1 concern: EVM tooling that trusts the type field without also checking network will attempt to use Tron addresses as EVM addresses, which will fail silently or throw. The risk is limited to the duration of the workaround, but downstream integrators need explicit guidance.
• tokens/token-list.json — the two Tron token entries with "type": "ERC20" need the accompanying caveat communicated to consumers.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Consumer fetches token-list v1.5.1] --> B{Filter by type}
    B -->|type === 'ERC20'| C[EVM token set\nETH, MATIC, BSC… tokens]
    B -->|type === 'ERC20'| D[⚠️ USDT-tron\nnetwork: tron\naddress: TR7NH…]
    B -->|type === 'ERC20'| E[⚠️ USDC-tron\nnetwork: tron\naddress: TEkxi…]
    B -->|type === 'TRC20'| F[Empty — no tokens match\nTRC20 temporarily unused]
    C --> G[EVM operation ✅]
    D --> H{Consumer checks network?}
    E --> H
    H -->|Yes — skips tron entries| I[Safe ✅]
    H -->|No — passes to EVM handler| J[Invalid address error ❌\ne.g. ethers.getAddress throws]

_{Last reviewed commit: "fix: remove trailing..."}

@greptileai review

Closing this, we decided to implement this bandaid on our API 👍